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Fig. 7 Example Descriptive Data Structure Format 
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TECHNIQUES FOR DEFINING USING AND 
MANIPULATING RIGHTS MANAGEMENT 
DATA STRUCTURES 

CROSS-REFERENCE TO RELATED 
APPLICATIONS 

This application is related to commonly assigned appli- 
cation Ser. No. 08/388,107 of Ginter et aL entitled "SYS- 
TEMS AND METHODS FOR SECURE TRANSACTION 
MANAGEMENT AND ELECTRONIC RIGHTS 
PROTECTION" filed on Feb. 13, 1995, now abandoned; 
and pending application Ser. No, 08/699,712 of GINTER et 
al. entitled "TRUSTED INFRASTRUCTURE SUPPORT 
SYSTEMS, METHODS AND TECHNIQUES FOR 
SECURE ELECTRONIC COMMERCE ELECTRONIC 
TRANSACTIONS AND RIGHTS MANAGEMENT" filed 
on Aug. 12, 1996, now pending. The entire disclosures, 
including the drawings, of those prior filed specifications are 
incorporated by reference into this application. 

FIELD OF THE INVENTION 

This invention relates to techniques for defining, creating, 
and manipulating rights management data structures. More 
specifically, this invention provides systems and processes 
for defining and/or describing at least some data character- 
istics within a secure electronic rights management con- 
tainer. The present invention also provides techniques for 
providing rights management data structure integrity, 
flexibility, interoperability, user and system transparency, 
and compatibility. 

BACKGROUND AND SUMMARY OF THE 
INVENTIONS(S) 

People are increasingly using secure digital containers to 
safely and securely store and transport digital content. One 
secure digital container model is the "DigiBox™" container 
developed by InterTrust Technologies Corp. of Sunnyvale, 
Calif. The Ginter et a 1. patent specification referenced above 
describes many characteristics of this DigiBox™ container 
model — a powerful, flexible, general construct that enables 
protected, efficient and interoperable electronic description 
and regulation of electronic commerce relationships of all 
kinds, including the secure transport, storage and rights 
management interface with objects and digital information 
within such containers. 

Briefly, DigiBox containers are tamper- resistant digital 
containers that can be used to package any kind of digital 
information such as, for example, text, graphics, executable 
software, audio and/or video. The rights management envi- 
ronment in which DigiBox™ containers are used allows 
commerce participants to associate rules with the digital 
information (content). The rights management environment 
also allows rules (herein including rules and parameter data 
controls) to be securely associated with other rights man- 
agement information, such as for example, rules, audit 
records created during use of the digital information, and 
administrative information associated with keeping the envi- 
ronment working properly, including ensuring rights and 
any agreements among parties. The DigiBox™ electronic 
container can be used to store, transport and provide a rights 
management interface to digital information, related rules 
and other rights management information, as well as to other 
objects and/or data within a distributed, rights management 
environment. This arrangement can be used to provide an 
electronically enforced chain of handling and control 
wherein rights management persists as a container moves 
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from one entity to another. This capability helps support a 
digital rights management architecture that allows content 
rightsholders (including any parties who have system autho- 
rized interests related to such content, such as content 

5 republishes or even governmental authorities) to securely 
control and manage content, events, transactions, rules and 
usage consequences, including any required payment and/or 
usage reporting. This secure control and management con- 
tinues persistently, protecting rights as content is delivered 
to, used by, and passed among creators, distributors, 
repurposcrs, consumers, payment disagregators, and other 
value chain participants. 

For example, a creator of content can package one or 
more pieces of digital information with a set of rules in a 
DigiBox secure container — such rules may be variably 

35 located in one or more containers and/or client control 
nodes — and send the container to a distributor. The distribu- 
tor can add to and/or modify the rules in the container within 
the parameters allowed by the creator The distributor can 
then distribute the container by any rule allowed (or not 

20 prohibited) means — for example, by communicating it over 
an electronic network such as the Internet. A consumer can 
download the container, and use the content according to the 
rules within the container. The container is opened and the 
rules enforced on the local computer or other InterTrust - 

25 aware appliance by software InterTrust calls an InterTrust 
Commerce Node. The consumer can forward the container 
(or a copy of it) to other consumers, who can (if the rules 
allow) use the content according to the same, differing, or 
other included rules — which rules apply being determined 

30 by user available rights, such as the users specific 
identification, including any class membership(s) (e.g., an 
automobile club or employment by a certain university). In 
accordance with such rules, usage and/or payment informa- 
tion can be collected by the node and sent to one or more 

35 clearinghouses for payment settlement and to convey usage 
information to those with rights to receive it. 

The node and container model described above and in the 
Ginter et al. patent specification (along with similar other 
DigiBox/VDE (Virtual Distribution Environment) models) 

40 has nearly limitless flexibility. It can be applied to many 
different contexts and specific implementations. For 
example, looking at FIGS. 1A and IB, a newspaper pub- 
lisher can distribute a newspaper 102 within a container 
100A. A publisher of fashion magazines 106 can distribute 

45 the fashion magazines within another container 100C. 
Similarly, for example, a wholesale banking environment 
may use yet a further container, an electronic trading system 
may use a still further container, and so on. 

The InterTrust DigiBox container model allows and 

50 facilitates these and other different container uses. It facili- 
tates detailed container customization for different uses, 
classes of use and/or users in order to meet different needs 
and business models. This customization ability is very 
important, particularly when used in conjunction with a 

55 general purpose, distributed rights management environ- 
ment such as described in Ginter, et al. Such an environment 
calls for a practical optimization of customizability, includ- 
ing customizability and transparency for container models. 
This customization flexibility has a number of advantages, 

60 such as allowing optimization (e.g., maximum efficiency, 
minimum overhead) of the detailed container design for 
each particular application or circumstance so as to allow 
many different container designs for many different pur- 
poses (e.g., business models) to exist at the same time and 

65 be used by the rights control client (node) on a user 
electronic appliance such as a computer or entertainment 
device. 
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While supporting a high degree of flexibility has great 
advantages, it can produce difficulties for the average user. 
For example, think of the process of creating a painting. A 
master painter creates a painting from a blank canvas. 
Because the canvas was blank at the beginning, the painter 5 
was completely unconstrained. The painting could have 
been a landscape, a portrait, a seascape, or any other 
image — limited only by the painter's imagination. This 
flexibility allows a master painter to create a masterpiece 
such as the "Mona Lisa." However, great skill is required to 1Q 
create a pleasing image starting from a blank canvas. As a 
result, an inexperienced painter cannot be expected to create 
a good painting if he or she begins with a blank canvas. 

Consider now an amateur painter just starting out. That 
person does not have the skill to transform a blank canvas to 
a pleasing image. Instead of spending years trying to acquire 15 
that skill, the amateur can go out and buy a "paint by 
numbers" painting kit. Instead of using a blank canvas, the 
amateur painter begins with a preprinted canvas that defines 
the image to be painted. By following instructions ("all areas 
labeled "12" should be painted with dark red," "all areas 20 
labeled with "26" should be painted with light blue"), the 
amateur can — with relatively little skill — paint a picture that 
is relatively pleasing to the eye. To do this, the amateur must 
rigidly adhere to the preprinted instructions on the canvas. 
Any deviations could cause the final image to come out 25 
badly. 

Ease of use problems in the computer field can be 
analogized to the "paint by numbers" situation. If it is 
important for untrained and/or inexperienced users to use 
particular software, the system designers can predefine cer- 30 
tain constructs and design them into the system. This tech- 
nique allows inexperienced users to make use of potentially 
very complicated designs without having to fully understand 
them — but this normally strictly defines, that is severely 
limits, the functionality and flexibility available by use of the 35 
program. As a result, creative solutions to problems are 
constrained in order to provide practical value. In addition, 
even the experienced user can find great advantage in using 
previously implemented designs. Because a user can pro- 
gram a complex program, for example, does not mean it is 40 
appropriate or efficient to create a program for a specific 
purpose, even if the previously implemented program is not 
ideal. If the creation of a new program "costs" more to 
create, that is takes too much time or financial resources, the 
experienced user will normally use a previously imple- 45 
mented program, if available. Therefore, the greatest total 
amount of value to be realized, related to customization, is 
to be able to customize with great ease and efficiency so that 
the cost of customization will not exceed the benefits. 

Uniformity, flexibility, compatibility and interoperability 50 
are other considerations that come into play in the computer 
field, particularly in regards to systems supporting customi- 
zation. In the painting situation, the human eye can appre- 
ciate uniqueness — and the "one of a kind" nature of a 
masterpiece such as the Mona Lisa is a big part of what 55 
makes a painting so valuable. In contrast, it is often desirable 
to make uniform at least the overall layout and format of 
things in the computer field. It is much more efficient for a 
computer to know beforehand how to treat and use objects. 
If the computer doesn't know beforehand how to read or 60 
handle an input object, for example, then the computer and 
the object are said to be "incompatible", i.e., they cannot 
work together. Computers are said to be "interoperable" if 
they can work together. Incompatibility and interoperability 
problems can prevent one computer from talking to another 65 
computer, and can prevent you from using computer data 
created by someone else. 
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For example, in the non-computer world, a Frenchman 
who knows only a little English as a second language, might 
find it far more meaningful and efficient to describe a 
complex problem in his native tongue, French. But if he is 
speaking to a second person, an Englishman, and the 
Englishman does not understand French, the two are not 
interoperable in French, and the Frenchman must resort to 
the far less efficient option of speaking in English to the 
Englishman. Of course, this is far better than if he was trying 
to speak to a German who understood neither English nor 
French. Then the two would be not be "interoperable" in 
regards to discussing the problem. Similarly, because rights 
management containers may potentially be exchanged and 
used for a large number of different purposes by a large 
number of different users, groups, and organizations, it is 
very important to provide compatibility and interoperability 
if these different parties, each participating in one or more 
different rights management models, are to intemperate 
efficiently. For example, if a rights management container is 
used to distribute a newsletter and is optimized for this 
purpose, each reader of the newsletter must have a computer 
system or software that "knows" how to read the container 
and the newsletter it contains. Since commerce, such as 
distributing newsletters, needs to be as efficient and cost- 
effective as is feasible, it is important to optimize, that is 
customize, rights management containers to optimally 
reflect the requirements of their models and not to have 
unnecessary features for each respective application or class 
of application, since unnecessary features will require 
unnecessary computing overhead and/or storage space. 

Different newsletter publishers may use different con- 
tainer formats customized to their own particular newsletters 
and/or content types and/or formats. A newsletter reader 
interested in many different newsletters may need to be able 
to read a large number of different formats. It normally will 
not efficient (or, due to security issues, may not be 
appropriate) simply to analyze the different containers upon 
delivery and "try to figure out" or otherwise discern the 
particular format in use. 

Published standards may help achieve a level of interop- 
erability and standards for given types of applications, but it 
generally takes a long time for any particular standard to 
achieve industry-wide acceptance and standards will need to 
vary widely between categories of applications. Moreover, 
data structure and other standards are often designed to the 
lowest common denominator — that is, they will carry fields 
and requirements not needed by some, and miss others 
features optimal in certain cases. There will always be 
applications that cannot be optimized for efficiency and/or 
operation if forced to use a specific standard. 

Trade-offs between flexibility, ease of use and incompat- 
ibility and interoperability can be further complicated when 
security considerations come into play. To be effective in 
many electronic commerce applications, electronic con- 
tainer designs should be tamper-resistant and secure. One 
must assume that any tools widely used to create and/or use 
containers will fall into the hands of those trying to break or 
crack open the containers or otherwise use digital informa- 
tion without authorization. Therefore, the container creation 
and usage tools must themselves be secure in the sense that 
they must protect certain details about the container design. 
This additional security requirement can make it even more 
difficult to make containers easy to use and to provide 
interoperability. 

The above- referenced Ginter et al. patent specification 
describes, by way of non-exhaustive example, "templates" 
that can act as a set (or collection of sets) of control 
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instructions and/or data for object control software. See, for specify where, in an associated rights management data 

example, the "Object Creation and Initial Control structure, corresponding defined data types may be found. 

Structures/' "Templates and Classes/' and "object definition The descriptive data structure may further provide metadata 

file," "information" method and "content" methods discus- that describes one or more attributes of the corresponding 

sions in the Ginter ct al. specification. The described tem- 5 rights management data and/or the processes used to create 

plates are, in at least some examples, capable of creating and/or ^ it [ n one example, the entire descriptive data 

(and/or modifying) objects in a process that interacts with structure might be viewed as comprising such metadata, 

user instructions and provided content to create an object. _ ,. • j * . . 

Ginter et al. discloses that templates may be represented, for ^ machine readable descriptive data structure may or 

example, as text files defining specific structures and/or ln may not be, m part or m whole, protected, dependuig on the 

component assemblies, and that such templates-with their 10 P articular aPPhcahon. Some machine readable descriptive 

4 , . 1 1 • „ data structures may be encrypted in whole or in part, while 

structures and/or component assemblies — may serve as , . , , .._,.«.«£. iL . 

, w , 4 i l- r>- . * . others might be maintained in clear to rm so that they are 

obiect authonne and/or obiect control applications. Ginter et & , „ , . . ; , 

al. says that templates can help to focus the flexible and eas,, y accessible- Some machine readable description data 

configurable capabilities inherent within the context of spe- „ structures, whether encrypted or not, may be in part or 

cific industries and/or businesses and/or applications by 15 wholly protected tor integrity using a cryptographic hash 

providing a framework of operation and/or structure to allow al g° nthnl ^ combination with a secrecy algorithm to form 

existing industries and/or applications and/or businesses to a cryptographic seal, and/or through use of other protection 

. , 4 f \ i , A t ♦ ♦* a- techniques (including hardware, e.g., secure semiconductor 

manipulate familiar concepts related to content types, dis- , , . , r • • x ^ 

. u u ■ • u • \ and/or hardware packaging protection means). I ne machine 

tribution approaches, pricing mechanisms, user interactions „ A , 

with content and/or related administrative activities, 20 readable descriptive data structures may themselves be 

budgets, and the like. This is useful in the pursuit of P«*aged within rights management data structures, and 

optimized business models and value chains providing the mles < e *' Permissions records) controlling their access and 

right balance between efficiency, transparency, productivity, use ma y be associated with them. 

e t c . In accordance with one aspect of how to advantageously 

The present invention extends this technology bv 25 use descriptive data structures in accordance with a pre- 
providing, among other features, a machine readable ferred embodiment of this invention, a machine readable 
descriptive data structure for use in association with a rights descriptive data structure may be created by a provider to 
management related (or other) data structure such as a describe the lavout of the Provider's particular rights man- 
secure container. In one example, the machine readable 3Q agement data structure(s) such as secure containers. These 
descriptive data structure may comprise a shorthand abstract descriptive data structure ("DDS") templates may be used to 
representation of the format of the data within a rights crcate containers. A choice among two or more possible 
management related data structure. This abstract data rep- DDSs ma y be based u P on one or more classes and/or onc or 
resentation can be used to describe a single rights manage- more classcs ma y be based 00 parameter data. The DDS may 
ment data structure, or it may be generic to a family of data 35 be loaded and used as the lavout ™ les for containers 
structures all following the format and/or other characteris- bem S created. The provider can keep the DDS private, or 
tics the abstract representation defines. The abstract repre- P ublish li so lhat other providers may create compatible, 
scntation may be used to create rights management data interoperable containers based on the same DDS. 
structures, allow others (including "other" rights manage- Descriptive data structures can also be used by a container 
ment nodes automatically) to read and understand such data 40 viewer, browser, reader, or any other end user application 
structures, and to manipulate some or all of the data struc- designed to work with containers. Truly generic viewers or 
tures. other applications can be written that can process a container 

The descriptive data structure can be used as a "template" in any format at least in part by making use of descriptive 

to help create, and describe to other nodes, rights manage- data structures. Thus, a descriptive data structure can be used 

ment data structures including being used to help understand 45 10 at least temporarily convert and/or customize a generic 

and manipulate such rights management data structures. viewer (or other application) into a specialized viewer (or 

In one particularly advantageous arrangement, the other application) optimized around one or more classes of 

machine readable descriptive data structure may be associ- containers. Additionally, specialized readers may be pro- 

ated with one or a family of corresponding rights manage- vided t0 efficiently process descriptive data structures to 

ment data structures— and may thus be independent of any so locate ke y media elemenls ( e *S» cover page, table of 

specific particular rights management data structure usage. contents, advertiser's index, glossary, articles, unprotected 

For example, a copy of the descriptive data structure may be preview, price, and/or rights information regarding viewing, 

kept with such data structures. Alternatively, some or all of Panting, saving electronically, redistributing, related bud- 

the descriptive data structure may be obtained from some- S ets and /° r other parameter information, etc.). 

where else (e.g., a clearinghouse or repository) and inde- 55 Suc h specialized readers can then seamlessly, 

pendently delivered on as-needed basis. transparently, and automatically process to present the user 

In accordance with one example, the machine readable with an easy-to-use interface (for example, an icon display 

descriptive data structure provides a description that reflects for each of the key media elements) optimized for the 

and/or defines corresponding structurc(s) within the rights specific application, container, and/or user. Different and/or 

management data structure. For example, the descriptive 60 differently presented, such elements may be displayed or 

data structure may provide a recursive, hierarchical list that otherwise employed based, for example, on the identity of 

reflects and/or defines a corresponding recursive, hierarchi- the US&T and/or user node, including, for example, taking into 

cal structure within the rights management data structure. In account one or more class attributes which can influence 

other examples, the description(s) provided by the descrip- such automated processing. 

tive data structure may correspond to complex, multidimen- 65 Two or more DDSs may be associated with a container 

sional data structures having 2, 3 or n dimensions. The and/or container contents, as well as, for example, one or 

descriptive data structure may directly and/or indirectly more user and/or node classes. A choice among two or more 
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possible DDSs for a given container and/or class of con- 
tainers and/or container contents may therefore be based 
upon one or more classes and/or one or more classes based 
on parameter data. Overall, this ability to easily characterize, 
and/or reuse stored, optimized, custom container models and 5 
subsequent transparency of translation from such custom- 
ized containers (e.g., specific DDSs) to general purpose 
rights management use is particularly useful. For example, 
where such customized DDSs can be used as a basis for the 
creation of customized, optimized display of container con- 10 
tent and/or control information to substantially improve the 
ease of use, efficiency, transparency, and optimization of a 
distributed, generalized rights management environment. In 
such an environment, for example, user nodes can interact 
with different DDSs to automatically adjust to the require- is 
ments of the commercial or other rights models associated 
with such DDSs. 

Some providers may spend considerable time designing 
sophisticated container descriptive data structures that 
describe the layout of their associated containers. With this 20 
type of investment in structure and format, the descriptive 
data structure will often have significant value in their reuse 
for the same or similar applications. Entities can use descrip- 
tive data structures in-house to ensure consistent and highly 
efficient creation of containers. Third party providers (i.e., a 25 
provider other than the one responsible for descriptive data 
structure creation) can use these descriptive data structures 
when they wish to create containers compatible with other 
entities. One example is where the publisher of a widely 
circulated newspaper develops a descriptive data structure 30 
for reading its newspaper. Other, smaller newspapers may 
want to leverage any viewers or other tools put in place for 
use with the widely circulated newspaper by adopting the 
same container format. Descriptive data structures can be 
copyrighted and/or otherwise protectable by both law and by 35 
the rights management system itself. For example, they may 
also be protected by their own containers and associated 
controls to ensure that descriptive data structure creators, 
and/or distributors and/or other users of such DDSs, receive 
their fair, rights system managed, return on their descriptive 40 
data structure creation and/or use related efforts. 

In addition to the foregoing, the following is a list of 
features and advantages provided in accordance with aspects 
of this invention: 

45 

Integrity Constraints: The descriptive data structure 
allows the provider to protect the integrity of his or her 
content, by enabling the specification of integrity con- 
straints. Integrity constraints provide a way to state 
integrity related rules about the content. 5Q 

Application Generation: The descriptive data structure 
can be used to generate one or more portions of 
software programs that manipulate rights management 
structures. For example, a descriptive data structure 
could serve as 'instructions' that drive an automated 55 
packaging application for digital content and/or an 
automated reader of digital content such as display 
priorities and organization (e.g., order and/or layout). 

Dynamic user interfaces for creation applications: Appli- 
cations can read a descriptive data structure to generate 60 
an interface optimized for data creation, editing, and/or 
composition for a specific model, including models 
involving, for example, composing complex content 
from textual, audio, video, and interactive (e.g., 
querying) elements. The data may take the form of a 65 
container, database and/or any other digital information 
organization as any simple or compound and complex 



file format. Applications can also read a descriptive 
data structure to learn how to best display an interface 
for collection and/or creation of content. 

Dynamic user interfaces for display applications: Appli- 
cations can read a descriptive data structure to and 
generate an interface appropriate for data display. This 
data may be a container, database or any other com- 
pound complex file format. Applications can also read 
a descriptive data structure to learn how to best display 
an interface for the presentation of content. Applica- 
tions can further read a descriptive data structure to 
learn how to manage display functions related to 
interacting — for content creation and/or packaging and/ 
or user display purposes including optimizing any of 
such interactions — with other one or more other 
applications, smart agents, computing environments, 
identity (including any class identities) of user and/or 
user nodes, etc. For example, a user interface might be 
differently optimized for interacting with: a member of 
the U.S. Air Force versus a faculty member in social 
sciences at a university; or a member of a Kiwanis Club 
versus a member of a Protestant church club, a citizen 
of the United States versus a citizen of Saudia Arabia, 
including an appropriate display of expected class 
membership symbols and related, appropriate organi- 
zation or suppression of displayed information. 

Ability to automatically identify and locate data fields: 
Full text search, agents, web spiders, and the like, 
benefit and are able to interact with information con- 
tained within one or more areas of a DDS when areas 
within a data file are known to contain potentially 
interesting information and such information is pre- 
sented in a predefined format. 

Ability to extract needed or desired data without first- 
hand knowledge of data format: Full text search, 
agents, web spiders, and the like, benefit and are able 
to interact with information contained within one or 
more areas of a DDS when large data files of arbitrary 
complexity and of unknown origin can be processed 
without special knowledge. 

Efficient, machine/human readable data abstract: The 
descriptive data structures can be optimally small, 
convenient, and cost-effective to process, transmit, 
and/or store. 

Reusable, salable — independent of actual data: Descrip- 
tive data structures may be arbitrarily complex and 
therefore potentially time consuming to construct and 
requiring certain expertise. This gives the descriptive 
data structure resale value. 

On-the-fly definition and redefinition of content layout: 
Working with a layout tool allows quick iterations 
(including editing and modifications) of a design 
(layout) which can be more convenient and cost- 
effective than creating such a layout, which also may be 
quite difficult or beyond the expertise of many users. 

Descriptive data structure attributes allow for meta- 
characteristics not found in actual data: Because the 
same descriptive data structure is processed by both the 
creation and post-creation processes, meta-information 
can be placed into the descriptive data structure that 
would otherwise be unavailable in the packaged con- 
tent. One example of this whether display of certain 
fields is "Required" or "Hidden". 

Enables design automation via descriptive data structure 
"wizards": Descriptive data structures themselves 
enable further automation in the way of "wizards". 
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There can, for example, be descriptive data structures 
that help to define other descriptive data structures. 
Descriptive data structures defining other descriptive 
data structures might represent the incomplete descrip- 
tive data structure for a book or magazine, for example. 
The "wizard" can comprise a series of dialog boxes 
displayed to the user to fill in the missing information 
to make it a completed descriptive data structure. 

Applications outside of a particular rights management 
architecture: For example, polymorphous applications 
may use descriptive data structures to determine certain 
data visualizations attributes and/or requirements, such 
as what look and feel should be displayed to the user. 
For example, if a descriptive data structure contains a 
word processing document reference, the polymor- 
phous application might create an interface appropriate 
for display and editing of a document. If the descriptive 
data structure contains references to many executable 
programs, the polymorphous application might ask the 
user where the files should be saved. 

Enables umbrella applications to process descriptive data 
structures and delegate unknown file types and pro- 
cesses: Umbrella (or polymorphous) applications can, 
for example, act substantially as an operation for a 
particular data file. This umbrella application may 
extract and process those things in the data file that it 
cares about, while ignoring or delegating (to, for 
example, user and/or value chain partner (e.g., 
distributor) to control display of such items) those 
things it does not understand. 

Runtime interpretation: It is possible to interpret a 
descriptive data structure at run time, providing mate- 
rially increased efficiencies and timeliness. 

Runtime adaptability: Systems can adapt to dynamic data 
arriving in real time through use of descriptive data 
structures. 

Automatic conversion capability: Descriptive data struc- 
tures be used for converting automatically from one 
format to another. 

Simplified system design: The use of descriptive data 
structures may greatly reduce the need for a secondary 
"wrapper" application programming interface (API) or 
other arrangement to securely "contain" the container 
creation process. Such a "wrapper" API to control and 
otherwise restrict the container creation process might 
otherwise be needed to ensure that all created contain- 
ers are compatible — thereby limiting flexibility and the 
ability to customize. 

Object oriented template programming environment: The 
use of display related, interaction related, and rights 
related concept objects which may be selected through 
high-level user interface choices and prioritizations and 
specification of related parameter data, this enabling 
very easy creation of certain categories of templates — 
such as construction and display hint information. 

The use of a template language and interpreter involving 
supporting programming through use of language ele- 
ments and interpretation of such language by nodes 
described in Ginter, et al., where such language 
includes elements descriptive of display, rights, and 
program interaction elements, priorities and parameter 
data. 

BRIEF DESCRIPTION OF THE DRAWINGS 

These and other features and advantages of presently 
preferred example embodiments in accordance with the 
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invention may be better and more completely understood by 
referring to the following detailed description along with the 
drawings, of which: 

FIGS. 1A and IB show example content containers; 
5 FIGS. 2A and 2B show example content containers asso- 
ciated with example descriptive data structures; 

FIG. 3 shows an example descriptive data structures 
creation and usage process; 
10 FIG. 4 shows another example creation and usage pro- 
cess; 

FIG. 5 shows an example system architecture using 
descriptive data structures; 

FIG. SAshows an example process performed by the FIG. 
15 5 system; 

FIG. 6 shows an hierarchical descriptive data structure 
organization; 

FIG. 6 A shows an example of how descriptive data 
2Q structures can be used with atomic transaction data; 

FIG. 7 shows an example descriptive data structure for- 
mat; 

FIG. 8 shows an example descriptive data structure cre- 
ation graphical interface; 
25 FIG. 9 shows an example process for tracking descriptive 
data structure rights management related data; 

FIG. 10 A shows an example use of descriptive data 
structures to provide interoperability between environments; 
and 

30 

FIG. 10B provides more detail about how the FIG. 10A 
example descriptive data structure may be organized. 

DETAILED DESCRIPTION OF PRESENTLY 
PREFERRED EXAMPLE EMBODIMENTS 

35 

FIGS. 2A and 2B show the example containers 100a, 
100c of FIGS. 1A, IB associated with machine readable 
descriptive data structures 200 and 200'. Referring to FIG. 
2 A, a descriptive data structure 200 is associated with 

40 content container 100a. This descriptive data structure 200 
may be used to define the content (and certain other 
characteristics) of container 100a. In the example shown, 
descriptive data structure 200 defines a number of sections 
of newspaper style content 102 such as, for example, the 

45 headline (descriptor 202a), the issue date (descriptor 2026), 
the lead story (descriptor 202c), breaking news (descriptor 
202</), image(s) (descriptor 202e), advertisement (descriptor 
202/), and section (descriptor 202g). 

The descriptive data structure definitions 202 in this 

50 example do not contain or specify the particular contents of 
corresponding portions of the newspaper 102, but instead 
define more abstractly, a generic format that a newspaper 
style publication could use. For example, the FIG. 2 A 
example descriptive data structure headline definition 202a 

55 does not specify a particular headline (e.g., "Yankees Win 
the Pennant!"), but instead defines the location (for example, 
the logical or other offset address) within the container data 
structure 100a (as well as certain other characteristics) in 
which such headline information may reside. Because 

60 descriptive data structure 200 is generic to a class or family 
of newspaper style content publications, it can be reused. 
For example, each daily issue of a newspaper might be 
created using and/or associated with the same descriptive 
data structure 200. By abstractly defining the data format 

65 and other characteristics of newspaper style content 102, the 
descriptive data structure 200 allows easy creation, usage 
and manipulation of newspaper style content 102. 
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Referring to FIG. 2B, a different descriptive data structure 
200' may be used to define another class of content publi- 
cations 106 such as fashion magazines. The descriptive data 
structure 200' for this content class reflects a different format 
(and possibly other characteristics) as compared to the 
descriptive data structure 200 shown in FIG. 2A. For 
example, since fashion magazines typically do not include 
headlines or breaking news, the example descriptive data 
structure 200' may not define such formatting. Instead, 
descriptive data structure 200' for defining a class of fashion 
magazine content may define issue date (descriptor 204a), a 
magazine title (descriptor 204ft), the name of a photographer 
(descriptor 204c) and associated artwork designation 
(descriptor 204t/). 

The FIGS. 2A and 2B examples show descriptive data 
structures 200, 200' being delivered within content object 
containers 100a, 100c along with associated content 102, 
106. However, other forms of association may be used. For 
example, descriptive data structure 200 can be indepen- 
dently delivered in its own separate container along with 
associated rules controlling its access and/or use. 
Alternatively, descriptive data structures 200 could be stored 
in a library and delivered on an as needed basis in secure or 
insecure form depending on particular requirements. 

In addition, although FIGS. 2A and 2B are printed pub- 
lication content examples, the use of descriptive data struc- 
tures 200 is not so limited. To the contrary, descriptive data 
structures 200 can be used to define the format and/or other 
characteristics associated with a wide variety of different 
types of digital information including for example: 

images 

sound 

video 

computer programs 
methods 
executables 
interpretables 
currency objects 

currency containers for currency objects 
rules 

any computer input 

any computer output 

other descriptive data structures 

any other information. 
Example Process For Creating and Using Descriptive Data 
Structures 

FIG. 3 shows an example process for creating and using 
descriptive data structures 200. In this example, a layout tool 
300 is used to create descriptive data structure 200. This 
layout tool 300 may be, for example, a so ftware-con trolled 
process interacting with a human being via a graphical user 
interface. The resulting descriptive data structure 200 
(which may be stored on a mass storage device or other 
memory) can then be used to facilitate any number of other 
processes to create or interpret stored data. For example, the 
descriptive data structure may be used in a creation process 
302. The creation process 302 may read the descriptive data 
structure and, in response, create an output file 400 with a 
predefined format such as, for example, a container 100 
corresponding to a format described by the descriptive data 
structure 200. A viewing process 304 may use the descrip- 
tive data structure 200 to locate important items in the output 
file 400 for display. A browsing process 306 may use the 
descriptive data structure 200 to locate items within the 
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stored output file 400 such as, for example, key words or 
other searchable text. Descriptive data structure 200 may 
supply integrity constraints or rules that protect the integrity 
of corresponding content during use of and/or access to the 
5 content. 

FIG. 4 shows a more detailed example descriptive data 
structure creation and usage process. In this example, the 
layout tool 300 may accept user input 310 provided via a 
graphical user interface 312. The output of the layout tool 

io 300 may be a descriptive data structure 200 in the form of, 
for example, a text file. A secure packaging process 302a 
may accept container specific data as an input, and it may 
also accept the descriptive data structure 200 as a read only 
input. The packager 302a could be based on a graphical user 

15 interface and/or it could be automated. The packager 302a 
packages the container specific data 314 into a secure 
container 100. It may also package descriptive data structure 
200 into the same container 100 if desired. A viewer 304 
may view data 314 with the assistance of the descriptive data 

20 structure 200 and in accordance with rules 316 packaged 
within the container applying to the data 314 and/or the 
descriptive data structure 200. 

Example Architecture For Using Descriptive Data Struc- 
tures 

25 FIG. 5 shows an example secure system architecture 
suitable for use with descriptive data structure 200. In this 
example, an electronic appliance 500 of the type described 
in the above-referenced Ginter et al. patent specification may 
be provided within a tamper resistant barrier 502. Electronic 

30 appliance 500 may include an application program interface 
(API) 504. One or more applications 506 may communicate 
with electronic appliance 500 via API 504. In some 
examples, the application 506 may execute on the secure 
electronic appliance 500. Each application 506 may include 

35 a descriptive data structure interpreter 508. In use, electronic 
appliance 500 may access secure container 100 and — in 
accordance with rules 316 — access the descriptive data 
structure 200 and content 102 it contains and provide it to 
application 506. 'llie interpreter 508 within application 506 

40 may, in turn, read and use the descriptive data structure 200. 
In addition, application 506 may be polymorphic in the 
sense that it can take on personality or behavior as defined 
at least in part by descriptive data structure 200. 

FIG. 5A shows an example detailed process performed by 

45 the FIG. 5 example secure system architecture. In this 
example, application 506 asks appliance 500 to retrieve the 
descriptive data structure 200 from container 100 (block 
550). Electronic appliance 500 reads the descriptive data 
structure 200 and, subject to the conditions specified by 

50 associated rules 316, provides the descriptive data structure 
200 to the application 506 (block 552). Application 506 then 
asks its interpreter 508 to interpret the descriptive data 
structure 200 (block 554). The interpreter 508 tells the 
application 506 what the descriptive data structure 200 says 

55 (block 556). The application 506 extracts or obtains the 
descriptive data structure information it needs or wants from 
interpreter 508 (block 558). For example, suppose the appli- 
cation 506 wants to display the "headline" information 
within newspaper style content shown in FIG. 2A. Appli- 

60 cation 506 may ask interpreter 508 to provide it with 
information that will help it to locate, read, format and/or 
display this "headline*' information. 

As another example, interpreter 508 may provide appli- 
cation 506 with an element identification (e.g., a hexadeci- 

65 mal value or other identifier) that corresponds to the head- 
line information within the newspaper style content (block 
558). Application 506 may then ask electronic appliance 500 
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to provide it with the Headline (or other) content informa- data structures 200 and associated control set(s) 316 relating 

tion 102 within container 100 by providing appropriate to a sequence of "events" 700 that define a real estate 

content information to electronic appliance 500 via API 504 transaction. The DDS 200 may, for example, include a 

(block 560). For example, application 506 may pass the number of different entries 200A-200N pertaining to each 

electronic appliance 500 the element ID that interpreter 508 5 different "event" within the transaction (e.g., "offer", 

provided to the application. Even though application 506 "acceptance", "purchase/sales", "inspection", "mortgage", 

may have no direct knowledge of what is inside container etc )- These entnes 200A-N may, for example, define where 

100 (and may only be able to access the container 100 in container 100 the event can be found. The entries 

through a secure VDE node provided by appliance 500), 200A-200N may also include metadata that provides addi- 

interpreter 508 (by looking at descriptive data structure 200) 10 tl0nal characteristics corresponding to the event (for 

can tell application 506 enough information so that the example, how certain information related to the event should 

application knows how to request the information it wants ^e displayed). 

from the electronic appliance 500. Example Descriptive Data Structure Formatting 

The electronic appliance may then access information 102 FIG - 7 shows an example of how descriptive data struc- 

within container 100, and deliver (in accordance with the is ture 200 may be formatted. As mentioned above, descriptive 

rules 316 within the container) the requested information to data structure 200 may comprise a list such as a linked list, 

the application 506 (block 562). The application 506 may Each list entrv 260 ( 1 )' 260 ( 2 )> • ■ * ma y include a number of 

then use the information electronic appliance 500 provides data fields including, for example: 

to it, based at least in part on what interpreter 508 has told an ob J ect name field 262, 

it about the content information (block 564). For example, 20 one or more metadata fields 264 (which may be part of 

the descriptive data structure 200 may provide characterise and/or referenced by the descriptive data structure); and 

tics about the way application 506 should handle the infor- location information 266 (which may be used to help 

mation 102. Descriptive data structure 200 can, for example, identify the corresponding information within the con- 

tell application 506 to always display a certain field (e.g., the tainer data structure 100). 

author or copyright field) and to never display other infor- 25 The object name field 262 may include a constant that 

mation (e.g., information that should be hidden from most may corresponds to or describes a type of information. For 

users). DDS 200 can also provide complete presentation or example, object name field 262 may act as a "handle" to the 

"visualization" information so that an information provider content or data; it may be an indirect reference to the content 

can, for example, control the look and feel of the information or data; and/or it may be used to look up the content or data. 

when it is displayed or otherwise rendered. Descriptive data 30 The following are examples of object names: 

structure 200 may provide encodings of other characteristics General Purpose Object Names 

in the form of metadata that can also be used by application NUMBER 

506 during a process of creating, using or manipulating STRING 

container 100. The DDS 200 can be used to generate a DATE 

software program to manipulate rights management struc- 35 TITLE 

tures. For example, a DDS 200 could serve as the 'instruc- DESCRIPTION 

tions' that drive an automated packaging application for AUTHOR 

digital content or an automated reader of digital content. PROVIDER 

Example Description(s) Provided by Descriptive Data MIME_TYPE 

Structure 40 VERSION 

FIG. 6 shows one example of how a descriptive data URL 

structure 200 may describe and define an arbitrarily EMAIL 

complex, information structure such as, for example, an NEWGROUP 

hierarchical container 100. In this particular example, con- FILE_NAME 

tainer 100 includes properties 600(1), 600(2). Property 600 45 KEYWORDS 

(1) may include n attributes 602(1), 602(2) . . . 602(n). CREATION_DATE 

Property 600(2) may include any number of attributes MODIFICATION_DATE 

604(1), 604(2), and it may also include an additional prop- LAST__ ACCESSED ATE 

erty 606. Property 606 may, in turn, include its own NAnVE_PLATFORM 

attributes 608(1), 608(2) .... Associated descriptive data 50 SIZE 

structure 200 may be organized as a tree structure list 250 CONTENT 

providing a recursive structure to reflect the recursive struc- PREVIEW 

ture of the contents of container 100. For example, list 250 THUMBNAIL 

may include "branches" in the form of "property" descrip- TEXT 

tors 252(1), 252(2) corresponding to properties 600(1), 55 ARTWORK 

600(2). Each property descriptor 252 may, in turn, include a ILLUSTRATION 

list 254 of attributes and may include additional property UNKNOWN 

descriptors 256 in the same recursive, hierarchical arrange- TEMPLATE 

ment as is reflective of the example content container BILLING_NAME 

structure. DDS 200 may be used to describe arbitrarily 60 CONTAINER 

complex, hierarchical or non-hierarchical data structures of Book -style Object Names 

any dimension (1 to n). DEADLINE JJATE 

FIG. 6 A shows that descriptive data structure 200 can be TTTLE_PAGE 

used in conjunction with any kind of information such as, for PROLOGUE 

example, events or methods defining an "atomic transac- 65 INTRODUCTION 

tion" such as a real estate transaction. In this FIG. 6 A ABSTRACT 

example, a container 100 includes one or more descriptive TABLE_OF_CONTENTS 
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The DDS 200 may include or reference any type of data 
or metadata. In one example, the DDS 200 uses the object 
name field 262 to points or refers to metadata. This metadata 
can define certain characteristics associated with the object 
name. For example, such metadata may impose integrity or 
other constraints during the creation and/or usage process 
(e.g., "when you create an object, you must provide this 
information*', or "when you display the object, you must 
display this information"). The metadata 264 may also 
further describe or otherwise qualify the associated object 
name. 

In one preferred example, the DDS 200 uses object name 
262 to refer to metadata stored elsewhere — such as in a 
container 100. This referencing technique provides several 
advantages. For example, one situation where it may be 
useful to store the metadata in a secure container 100 
separately from DDS 200 is in situations where it is desir- 
able to make the DDS readily accessible to an outside 
application but to protect the associated metadata. For 
example, consider the case of handling web spider queries. 
A web spider may query the DDS 200 for a particular object 
name 262. If the object name is found, then the web spider 
may request the corresponding metadata. The web spider 
may have ready access to the metadata, but may only be able 
to access the associated metadata from the container 100 
under appropriate conditions as controlled by a correspond- 
ing secure electronic appliance 500 based on associated 
rules 316. As another example, storing metadata separately 
from the DDS 200 may allow the same DDS to be used with 
different metadata in different contexts. Suppose for 
example that a DDS 200 contains an Object Name, for 
example KEYWORDS. When DDS 200 is associated with 
container 100A, then the DDS Object Name KEYWORDS 
refers to container lOOA's KEYWORDS metadata. 
Conversely, if later this same DDS 200 is associated (e.g., 
packaged with) a different container 100C, then the DDS 
Object Name KEYWORDS refers to container lOOB's 
KEYWORDS data. 

Although it is preferred to use object name 262 to refer to 
metadata stored elsewhere, there may be other instances 
where there is a need or desire to explicitly include metadata 
within the DDS 200. For purposes of illustration, FIG. 7 
shows an example DDS 200 that includes metadata field 264 
and also refers to metadata within a container 100 using the 
object name 262. Either or both techniques may be used. 

ITie DDS 200 thus allows value chain participants to 
protect the integrity of content, by enabling the specification 
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of integrity constraints. DDS 200 integrity constraints pro- 
vide a way to state rules about the content. For example, 
DDS 200 can specify that an article of a newspaper cannot 
be viewed without its headline being viewed. The corre- 
5 sponding integrity constraint can indicate the rule ' if there is 
an article, there must also be a headline". Another example 
is a photograph that is part of a magazine and the credit that 
goes with it. The integrity constraint rule provided by DDS 
200 might be 'do not present this photograph without its 
1Q associated credit*. 

DDS integrity constraints give value chain participants a 
tool for protecting the use of the DDS 200, ensuring that 
content represented by a particular DDS contains all the 
essential components — that it is representative of the DDS. 
This gives providers a way to set up conventions and enforce 
15 standards of use. There arc many possible integrity con- 
straints. The following are a few examples: 
Required: a is required as part of the content 
Optional: a is an optional component of the content 
Required relationship: if a is present, then b must be 
20 present, or if a is present b, c and d must be present. 
Conversely, if b is not present, then a is not allowed to 
be present. Relationships in this category are l:m 
where m>0. 

Optional relationship: If a is present b may or may not be 
25 present. If b is present, then a is guaranteed to be 
present. Relationships in this category arc l:n, where 
n>=0. 

Repetition: a must occur n times where n>l. This could be 
specified with ranges of values, etc. 
30 Other rules and/or requirements. 
Metadata 264 

Example Graphical Interface For Creating Descriptive Data 
Structures 

FIG. 8 shows an example descriptive data structure cre- 
35 ation graphical user interface 312. In this example, the 
graphical user interface 312 may prompt the user for the 
object name. In addition, the graphical user interface 312 
may provide options for specifying the associated metadata 
264. The options shown in FIG. 8 may, for example, 
40 include:) 

"construction type" metadata (upon object construction, 
the information is required; upon object construction, 
the object creation tool is to always or never prompt for 
the information); 
45 display metadata (e.g., always display the associated 
information (e.g., for copyright notices, author names 
and the like) or always or never make the information 
visible; and/or 
layout "hints" and field definitions (e.g., text, text block, 
50 integer, file, image or other data type). 

The above metadata descriptions are non-limiting examples. 
Other metadata characteristics and attributes may be used. 
Example Process Using Descriptive Data Structures 
FIG. 9 shows one example arrangement for using the 
55 infrastructure described in co-pending related U.S. patent 
application Ser. No. 08/699,712 (referenced above) for 
descriptive data structures 200. The arrangement shown in 
FIG. 9 may be useful in a number of different contexts. For 
example, a provider 600 of descriptive data structures 200 
60 may want to know which descriptive data structures 200 are 
the best liked by his customers so he or she can improve the 
quality of his products. Or, a provider 600 may charge 
customers for using descriptive data structures 200 on a per 
use or other basis. In still another example, some descriptive 
65 data structures 200 or classes of DDS 200 may be restricted 
to use only by authorized users or classes of authorized 
users. 
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FIG. 9 shows a DDS provider 600 who delivers a DDS 
200 and an associated control set 316 to a value chain 
participant 602. Controls 316 may provide rules and asso- 
ciated consequences for controlling or otherwise affecting 
the use or other aspects of what value chain participant 602 
can do with DDS 200. The controls 316 and DDS 200 may 
be packaged within a container 100. Value chain participant 
602 may get the container 100 containing DDS 200 directly 
from DDS provider 600; alternatively, the provider can 
provide it a rights and permissions clearinghouse 604 and 
participant 602 and get it from the clearinghouse (or 
elsewhere) (see container 100B). 

Value chain participant 602 can use DDS 200 to author 
content 102. Participant 602 can package content 102 with 
associated controls 316A in a container 100A. Participant 
600 may, if he desires, include DDS 200 and associated 
controls 316a, 3166 with content 102 in the same 
container — or depend on the provider 600 and/or rights and 
permissions clearinghouse 604 to independently deliver the 
DDS and its controls to end users 606 in another container 
100c for example. 

End users 606(1), . . . , 606(n) use DDS 200 (in accor- 
dance with controls 316) in conjunction with content 102 
(for example, to read, browse or otherwise access the 
container content). Controls 316, 31 6 A may require user 
appliances to provide usage data 610 to a usage clearing- 
house 612. The usage clearinghouse 612 can provide usage 
data 610A related to access and/or usage of DDS 200 to 
DDS provider 600, and may independently provide usage 
data 610B related to access and/or usage of content 102 to 
value chain participant 602. 

Descriptive Data Structures Can Be Used to Achieve A 
Degree of Interoperability Between Rights Management 
Environments 

Descriptive data structures 200 provided in accordance 
with the present invention can provide a degree of interop- 
erability between source and target rights management 
environments, and/or to provide a bridge to achieve at least 
some degree of inleroperatibility between a rights manage- 
ment environment and the outside world. 

Different rights management environments may have 
substantially incompatible mechanisms for defining rights 
pertaining to an object. Descriptive data structures 200 can 
provide at least a partial bridge to achieve a degree of 
compatibility and interoperability. For example, a provider 
that defines an object within a source rights management 
environment may create a descriptive data structure for use 
by processes within one or more target rights management 
environments. For example, an object creator or other pro- 
vider can specify, within a descriptive data structure 200, 
certain rules, integrity constraints and/or other characteris- 
tics that can or should be applied to the object after it has 
been imported into a target rights management environment. 
The target rights management environment can choose to 
selectively enforce such rules, constraints and/or other char- 
acteristics depending on the degree to which it can trust the 
source environment. For example, objects imported from an 
EDI system employing X.12 security may be more trust- 
worthy than objects presented from environments with 
lesser (or no) security. 

In another example, a provider that creates an object 
outside of any rights management environment can create a 
descriptive data structure 200 for use if and when the object 
is imported into one or more rights management environ- 
ments. The target rights management environment(s) can 
use such descriptive data structure(s) to help efficiently 
understand and handle the object. Further, a descriptive data 
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structure created within a rights management environment 
can be exported to one or more applications outside of the 
rights management environment and used to assist the 
application(s) in interpreting exported content or other infor- 
5 mation. 

FIG. 10A shows an example of how descriptive data 
structures 200 may be used to provide interoperability. In the 
FIG. 10A example, a DDS creation tool 800 creates a DDS 
200 that includes one or more target data blocks 801. In one 

1Q example, the DDS creation tool 800 may be based on, and/or 
incorporate some or all of the capabilities of layout tool 300 
and provide interoperability capabilities in addition to fea- 
tures associated with layout tool 300. In another example, 
DDS creation tool 800 may not incorporate any of the 

15 capabilities of layout tool 300, and may create DDS 200 
solely for interoperability purposes. DDS creation tool 800 
may, for example, be an application program with a graphi- 
cal user interface, a background process that only displays a 
user interface when being configured by a user, a portion of 

20 an operating system, a portion of a computer's firmware, a 
server process that may act independently or as part or all of 
a "gateway*' between one system and another (e.g., a public 
network and a private network, two or more private 
networks, a local area network and a wide area network, 

25 etc.), or any other desirable implementation or integration. 
Target data block 801 may provide information used to 
provide interoperability with a particular target environment 
850. A single DDS 200 can, in one example, provide 
interoperability with N different target environments 850 by 

30 including N target data blocks 801(1), . . . 801(N) each 
corresponding to a different target environment 850(1), . . . 
850(N). 

In this example, each target data block 801 includes rule 
(control) information. Different target data blocks 801 can 
35 provide different rule information for different target envi- 
ronments 850. The rule information may, for example, relate 
to operations (events) and/or consequences of application 
program functions 856 within the associated target environ- 
ment 850 such as specifying: 
40 permitted and/or required operations; 

nature and/or extent of operations permitted and/or 

required operations; and/or 
consequences of performing permitted and/or required 
operations. 

45 The target data block 801 may also include additional 
information if desired that gives directions to a DDS parser 
852 and/or a translator 854 within a corresponding target 
environment 850. 

FIG. 10B shows one detailed example of how target 

so information may be organized within DDS 200. In this 
example, DDS creation tool 800 creates a DDS header 805 
that references one or more target record headers 807. DDS 
header 805 may, for example, include a "number of targets" 
field 809 indicating the number of target data blocks 801 

55 within the DDS 200, a "offset to first target data portion" 
field 811 that provides the location of the first target data 
block 801 (1) within the DDS 200, a source message field 
812A that identifies the source environment, and an optional 
creator seal 812B that may be used to verify the integrity and 

60 authenticity of the DDS 200. Source message field 812A 
(which can be optional) may include a source ID that may 
be used to help verify the source environment of DDS 200, 
and an optional source seal (that may or may not be present 
in the source message). Each target data block 801 within 

65 DDS 200 may begin with a target record header 807 
including a "target ID" field 813, a "length" field 815, a 
"offset to next target data portion" field 817, an optional 
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creator seal 819, and an optional source message 821. The 
"target ID" field 813 may specify a unique identification 
number or value corresponding to the associated target data 
block 801 and/or identifying the intended target 
cnvironment(s), the "length" field 815 may specify the 5 
length of the target data block 801, and the "onset" field 817 
may specify the location (relative or absolute) of the next 
target data block 801 within the DDS 200 (and may take on 
a null value for the last target data block). 

The optional creator seals 812B, 819 (and source seals) 10 
may be cryptographic seals that help to ensure that the DDS 
200 and target records 801, respectively, have not be altered 
since they were created, and also the identity of the DDS 
201)' s creator and/or source. The optional source messages 
812C and 821 may be information that helps to ensure that is 
a target environment knows which source environment 
created DDS 200. 

Referring again to FIG. 10A, DDS creation tool 800 may, 
upon creating the DDS 200, cryptographically seal it and 
each target data block 801 for integrity using appropriate 20 
cryptographic processes, for example by first running a 
cryptographic hash function (e.g., SHA, MD5, etc.) on the 
data and then encrypting the resulting hash value using a 
private key of the DDS creator associated with an asym- 
metric cryptosystem (e.g., RSA, El Gamal, etc.). If sealing 25 
is used, the DDS creator preferably should ensure that the 
public key associated with the encrypting private key is 
certified (e.g., encrypted with a private key of a certifying 
authority) and available for use by target environments to 
validate the seal (e.g., by including a certificate in DDS 200, 30 
publishing the certificate on a public network, etc.) 

If source messages 812C, 821 are used, they should 
preferably represent information provided by the source 
environment that may help a target environment identify the 
source environment, and further may also help to ensure that 35 
the DDS 200 was actually created by the source environ- 
ment (and therefore may, for example, be trusted to the 
extent that the source environment is trusted). For example, 
a source environment may have a protected processing 
environment (PPE) of the form described in the above 40 
referenced Ginter, et al. patent application. Certain of such 
PPEs may have cryptographic keys (e.g., a private key of a 
public key/private key pair) available that may be used to 
encrypt a cryptographic hash taken of the DDS header 805 
or target block header 807, as appropriate. In such an 45 
example, a target environment would need to acquire a 
corresponding cryptographic key (e.g., a public key of a 
public key/private key pair) using trusted techniques (e.g., 
delivery in a certificate signed by a trusted certifying 
authority) in order to evaluate such a source message. In 50 
another example, DDS creation tool 800 may have been 
equipped with cryptographic keys when it was 
manufactured, and may use these cryptographic keys instead 
of keys from a PPE, although generally this technique would 
be more susceptible to tampering by an experienced com- 55 
puter hacker and might therefore be somewhat less trusted 
by target environments. 

In addition, or alternatively (for example, if cryptographic 
techniques are not appropriate or desired), the source mes- 
sage may contain a unique identifier that corresponds to the 60 
source environment. 

The DDS creation tool 800 (see FIG. 10A) may then 
package the resulting DDS 200 into a secure container 100 
along with an associated object 830. In another example, 
DDS creation tool 800 may embed DDS 200 within, or 65 
otherwise associate the DDS with, an object 830' that 
provides a method for releasing the DDS to the target 
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environment parser 852. The DDS 200 and its associated 
object 830 may then be delivered to one or more target 
environments 850 for processing. 

Target environment parser 852 (and/or translator 854) 
may, for example, be part of an application program, part of 
an operating system, or part of a utility program used by, or 
in conjunction with, an application program and/or an oper- 
ating system. The target environment parser 852 receives the 
DDS 200 and parses it to locate the target data block 801(k) 
corresponding to the target environment 850(k). Parser 852 
may then determine, from the corresponding target data 
block 801, the rules the target data block contains. Parser 
852 preferably understands enough about the structure of 
DDS 200 to find (e.g., using the header information shown 
in FIG. 10B) the appropriate target data block 801 corre- 
sponding to it, and also to understand the rules within the 
target data block. The target environment parser 852 doesn't 
need to understand any additional rules 316 that may be 
packaged within container 100 or otherwise delivered with 
object 830, but it may use any such additional rules if desired 
(e.g., when it finds no target data block 801 within DDS 200 
for the particular target environment 850 (for example, if it 
is capable of understanding some other target data block 801 
whose rules are based on a published specification and/or 
standard)). 

The target environment parser 852 may obtain applicable 
target rules from target data block 801 and provide these 
rules to application program functions 856. Application 
program functions 856 may define any operation pertaining 
to object 830 such as for example: 

cut 

copy 

print 

paste 

save 

change 

delete 

any other operation. 

The target rules provided by parser 852 may be used, for 
example, to permit, require and/or prevent certain opera- 
lions; to define the extent to which certain operations can be 
performed (e.g., limit number of copies, define extent of cut, 
the rules that should be applied to cut information in 
subsequent use, etc.); and/or to define the consequences of 
performing a particular operation (e.g., charge the user for 
printing or otherwise using and/or accessing all or part of 
object 830, maintain records of the time and/or number of 
such operations performed, etc.). 

Parser 852 may also, or alternatively, provide some or all 
of the rules it obtains from target data block 801 to other 
arrangements for applying the rules such as, for example, the 
"other rights management functions" block 858. Block 858 
may provide any kind of rights management functions. 
Translator 854 may be used if needed to allow the applica- 
tion program functions 856 and/or the "other rights man- 
agement" block 858 to understand the rules. As one 
example, translator 854 may be used to further elaborate, 
parameterize and/or secure the rule information obtained 
from target data block 801 so they arc more or fully 
compatible with the "other rights management functions" 
block 858. 

A useful data structure definitional method and arrange- 
ment has been described in connection with its most prac- 
tical and presently preferred example embodiments. The 
present invention is not to be limited to those embodiments, 
but on the contrary, is intended to encompass variations and 
equivalents as defined within the spirit and scope of the 
claims. 
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We claim: 

1. A distributed data processing arrangement including: 
a first data processing apparatus including: 

a central processing unit; 

a first memory storing a descriptive data structure, said 

descriptive data structure including: 

information regarding a first organization of ele- 
ments within a secure container, said information 
including: 

information on the organization of said elements 

within said secure container; and 
information on the location of at least some of 
said elements within said secure container; 
communications means by which said descriptive data 
structure may be communicated to a data processing 
apparatus different from said first data processing 
apparatus; 

a second data processing apparatus located at a site 
different from the site of said first data processing 
apparatus, said second data processing apparatus 
including: 

a central processing unit; 
a second memory including: 

a first secure container comprising at least: 

data elements organized at least in part in accor- 
dance with the information contained in said 
descriptive data structure; and 
at least one rule used to at least in part govern at 
least one aspect of access to or use of said data 
elements; 

at least one of said rules requiring that informa- 
tion regarding at least one use of at least one of 
said data elements be at least temporarily 
recorded; and 

at least one computer program designed to use at 
least a portion of said descriptive data structure 
in at least one operation on said first secure 
container or the contents of said first secure 
container; 

said use including at least using said information 
regarding the organization of elements within 
said first secure container in a process of 
identifying and/or locating at least one of said 
elements; and 
communications means by which said second data 
processing apparatus may receive at least a portion 
of said descriptive data structure or a copy thereof. 

2. A distributed data processing arrangement as in claim 
1 in which: 

said application includes a browser that uses said infor- 
mation regarding the organization of elements within 
said first secure container to control, at least in part, the 
display of at least some information from said secure 
container. 

3. A distributed data processing arrangement as in claim 
1, in which: 

said computer program is integrated into an operating 
system. 

4. A distributed data processing arrangement as in claim 
3, in which: 

said operating system is compatible with at least one 
version of Microsoft Windows. 

5. A distributed data processing arrangement as in claim 
1, in which: 

said descriptive data structure is contained within a sec- 
ond secure container; 
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said second secure container comprising at least: 
said descriptive data structure; and 
at least one rule governing at least in part at least one 

use of at least a portion of said descriptive data 

structure. 

6. A distributed data processing arrangement as in claim 

5, in which: 

said computer program includes means for using said 
second container rule to govern at least one aspect of 
said computer program's use of said descriptive data 
structure. 

7. A distributed data processing arrangement as in claim 

6, further including: 

metadata relating to the contents of said first secure 
container. 

8. A distributed data processing arrangement as in claim 

7, in which said metadata is stored in said second secure 
container. 

9. A distributed data processing arrangement as in claim 
7, in which said metadata is stored in a third secure con- 
tainer. 

10. A distributed data processing arrangement as in claim 
9, further including: 

a third data processing apparatus, including: 
a central processing unit; 
a third memory including: 

a third secure container including 
said metadata; and 

at least one rule used to at least in part govern at 
least one aspect of access to or use of said 
metadata; and 
communications means by which said third data pro- 
cessing apparatus may communicate said third 
secure container, or a copy of said third secure 
container, to said second data processing apparatus. 

11. A distributed data processing arrangement as in claim 
1, in which: 

said rules include at least one rule at least in part con- 
trolling at least one aspect of an auditing process. 

12. A distributed data processing arrangement as in claim 
1, in which: 

said rules include at least one rule at least in part con- 
trolling at least one aspect of a budgeting process. 

13. A distributed data processing arrangement as in claim 
1, in which said second data processing apparatus includes 
a secure electronic appliance. 

14. A method of using a descriptive data structure, at a 
first data processing arrangement located at a first site, said 
method comprising: 

at a communications port of said first data processing 
arrangement, receiving a first secure container from a 
site remote from said first site, said first secure con- 
tainer comprising at least (a) content and (b) at least one 
rule designed to at least in part govern at least one use 
of or access to said content, said governance including 
at least a requirement that at least some information 
relating to said use or access be at least temporarily 
stored; 

at said communications port, receiving a second secure 
container from a site remote from said first site, said 
second secure container comprising at least (a) a 
descriptive data structure including information at least 
in part describing or representing at least one aspect of 
the organization of said first secure container content; 
and (b) at least one rule designed to at least in part 
govern at least one use of or access to said descriptive 
data structure; 
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using said second container rule to gain access to at least 
a portion of said descriptive data structure; and 

using said descriptive data structure portion in the process 
of making at least one use of said first secure container 
content 5 

15. A method as in claim 14, in which: 

said use of said descriptive data structure portion includes 
using information from said descriptive data structure 
relating to the organization of said first secure container 
content. 10 

16. A method as in claim 15, in which: 

said use of said descriptive data structure portion further 
includes using said organization information to identify 
a specific portion of said first secure container content. J5 

17. A method as in claim 16, in which: 

said specific portion of said first secure container contents 
includes information identifying or describing at least 
one additional portion of said first secure container 
contents; and 20 

said use of said descriptive data structure portion is 
followed by displaying said identification or descrip- 
tion information. 

18. A method as in claim 17, in which: 

said first secure container contents identification or 25 
description information includes a title of said addi- 
tional portion of said first secure container contents. 

19. A method as in claim 17, in which: 

said first secure container contents identification or 
description information includes a summary of said 30 
additional portion of said first secure container con- 
tents. 

20. A method as in claim 16, in which: 

said first data processing arrangement further includes a 35 
first computer program including a descriptive data 
structure interpreter; and 

said step of using said descriptive data portion includes 
said first computer program making said use. 

21. A method as in claim 20, in which: 40 
said first computer program includes a browser, and 

said step of using said descriptive data structure portion 
further includes 

said browser using said descriptive data structure to 
identify and locate a portion of said first secure 45 
container content; and 

said browser causing the display of said located first 
secure container content portion. 

22. A method as in claim 21, in which: 

said step of said browser using said descriptive data 50 
structure to identify and locate a portion of said first 
secure container content further includes said browser 
receiving an element identifier from said descriptive 
data structure, said element identifier identifying said 
first secure container content portion; and 55 

said step of said browser causing the display of said 
located first secure container content portion further 
includes said browser accessing said first secure con- 
tainer content portion using said element identifier. 6Q 

23. A method as in claim 22, further comprising: 
following said identification, using at least one rule from 

said first secure container rules to access said identified 
first secure container content portion. 

24. A method as in claim 23, further comprising: 65 
at said communications port, receiving a third secure 

container including (1) metadata related to said descrip- 
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live data structure; and (2) at least one rule designed to 
at least in part govern at least one use of or access to 
said metadata; and 
said step of using said descriptive data structure further 
including: 

in said descriptive data structure, accessing a reference 

to said metadata; 
using at least one rule from said third container to 

access at least a portion of said metadata; and 
using said metadata in the process of using said 

descriptive data structure in connection with making 

said use of said third secure container contents. 

25. A method as in claim 24, in which: 

said step of using said metadata includes using informa- 
tion contained in said metadata to at least in part 
determine whether at least a portion of said first secure 
container content should be displayed to a user. 

26. A method as in claim 25, wherein using said metadata 
includes: 

the metadata includes information specifying that speci- 
fied information must be displayed if some or all of said 
first secure container contents are displayed; and 

said step of using said metadata includes displaying the 
specified information. 

27. A method as in claim 26, in which: 

said specified information includes information identify- 
ing at least one owner or creator of at least a portion of 
said first secure container content 

28. A method as in claim 24, in which: 

said first secure container is received from a second data 
processing arrangement; and 

said second secure container and said third secure con- 
tainer are received from a third data processing 
arrangement; 

said second data processing arrangement and said third 
data processing arrangement being located at locations 
separate from each other, and each separate from the 
site at which said first data processing arrangement is 
located. 

29. A method as in claim 14, in which: 

said first secure container and said second secure con- 
tainer are received at said first data processing arrange- 
ment at different times. 

30. A method as in claim 14, in which: 

said first secure container is received from a second data 
processing arrangement; and 

said second secure container is received from a third data 
processing arrangement; 

said second data processing arrangement and said third 
data processing arrangement being located at locations 
separate from each other, and each separate from the 
site at which said first data processing arrangement is 
located. 

. 31. A method as in claim 14, in which: 
said governance further includes at least in part control- 
ling at least one aspect of an auditing process. 

32. A method as in claim 14, in which: 

said governance further includes at least in part control- 
ling at least one aspect of a budgeting process. 

33. A method as in claim 14, in which said first data 
processing arrangement includes a secure electronic appli- 
ance. 

34. A descriptive data structure embodied on a computer- 
readable medium or other logic device including the fol- 
lowing elements: 
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a representation of the format of data contained in a first 
rights management data structure 
said representation including: 

element information contained within said first rights 

management data structure; and 5 
organization information regarding the organization 
of said elements within said first rights manage- 
ment data structure; and 
information relating to metadata, said metadata including: 
metadata rules used at least in part to govern at least one 10 
aspect of use and/or display of content stored within a 
rights management data structure, 
said metadata rules including at least one rule specifying 
that information relating to at least one use or display 
of said content be recorded and/or reported. 15 

35. A descriptive data structure as in claim 34, in which: 
said first rights management data structure comprises a 

first secure container. 

36. A descriptive data structure as in claim 35, in which: 
said first secure container comprises: 20 

said content; and 

rules at least in part governing at least one use of said 
content. 

37. A descriptive data structure as in claim 36, wherein the 
descriptive data structure is stored in said first secure con- 25 
tainer. 

38. A descriptive data structure as in claim 36, in which: 
said metadata is stored outside said descriptive data 

structure; and 

said information relating to metadata includes informa- 30 
tion regarding the location at which said metadata is 
stored. 

39. A descriptive data structure as in claim 38, in which: 
said metadata is stored in a second secure container. 

40. A descriptive data structure as in claim 36, in which: 35 
said metadata includes at least one display rule at least in 

part governing the display of at least a portion of said 
content. 

41. A descriptive data structure as in claim 40, in which: 
said content includes source information at least in part 

identifying an author, creator, publisher and/or owner 
of at least a portion of said content; and 
said metadata display rule requires display of said source 
information under circumstances specified by said 45 
metadata display rule. 

42. A descriptive data structure as in claim 35, in which: 
said metadata rules include at least one creation rule at 

least in part governing the creation of a specific 
example of said first secure container. 50 

43. A descriptive data structure as in claim 42, in which: 
said metadata creation rules include at least one rule at 

least in part specifying at least some information which 
must be included with said specific example of said first 
secure container when said specific example is created. 55 

44. A descriptive data structure as in claim 34, further 
including: 

a representation of the format of data contained in a 
second rights management data structure, 
said second rights management data structure differing 60 
in at least one respect from said first rights manage- 
ment data structure. 

45. A descriptive data structure as in claim 44, in which: 
said information regarding elements contained within said 

first rights management data structure includes infor- 65 
malion relating to the location of at least one such 
element. 
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46. A descriptive data structure as in claim 44, further 
including: 

a first target data block including information relating to 
a first target environment in which the descriptive data 
structure may be used. 

47. A descriptive data structure as in claim 46, further 
including: 

a second target data block including information relating 
to a second target environment in which the descriptive 
data structure may be used, 

said second target environment differing in at least one 
respect from said first target environment. 

48. A descriptive data structure as in claim 46, further 
including: 

a source message field containing information at least in 
part identifying the source for the descriptive data 
structure, 

49. A descriptive data structure as in claim 48, in which: 
said source identification information includes informa- 
tion relating to at least one aspect of the source envi- 
ronment in which said descriptive data structure was at 
least in part created. 

50. A descriptive data structure as in claim 49, in which: 
said information relating to at least one aspect of said 

source environment includes information relating to 
security present at said source environment. 

51. A descriptive data structure as in claim 49, in which: 
said source message field further contains a source seal. 

52. A descriptive data structure as in claim 51, in which: 
said source seal is encrypted based on a private key 

present at said source environment. 

53. A descriptive data structure as in claim 52, in which: 
said source seal includes a hash of at least a portion of said 

descriptive data structure. 

54. A descriptive data structure as in claim 52, further 
including: 

information related to a certificate from which a public 
key corresponding to said private key may be obtained. 

55. A descriptive data structure as in claim 52, in which: 
said certificate is stored in said descriptive data structure. 

56. A descriptive data structure as in claim 34, in which: 
said metadata rules include at least one rule at least in part 

controlling at least one aspect of an auditing process. 

57. A descriptive data structure as in claim 34, in which: 
said metadata rules include at least one rule at least in part 

controlling at least one aspect of a budgeting process. 

58. A method of creating a first secure container, said 
method including the following steps; 

accessing a descriptive data structure, said descriptive 
data structure including or addressing 
organization information at least in part describing a 
required or desired organization of a content section 
of said first secure container, and 
metadata information at least in part specifying at least 
one step required or desired in creation of said first 
secure container; 
using said descriptive data structure to organize said first 

secure container contents; 
using said metadata information to at least in part deter- 
mine specific information required to be included in 
said first secure container contents; and 
generating or identifying at least one rule designed to 
control at least one aspect of access to or use of at least 
a portion of said first secure container contents. 
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59. A method as in claim 58, in which: 

said descriptive data structure is contained in a second 
secure container, said second secure container gov- 
erned by at least one rule at least in part governing at 
least one use of said descriptive data structure; and 5 

said step of accessing said descriptive data structure 
includes complying with said second secure container 
rule. 

60. A method as in claim 59, in which: 

said second secure container rule requires the communi- 
cation of certain information to an external site; and 

said step of complying with said second secure container 
rule includes initiating and completing said required 
communication. 35 

61. A method as in claim 60, in which: 

said communicated information at least in part relates to 
the identity of the site at which said descriptive data 
structure is used in the process of creation of said first 
secure container and/or to the identity of a user at said 20 
site. 

62. A method as in claim 59 in which 

said second secure container further includes said first 
secure container rule; and 

said step of generating or identifying said first secure 25 
container rule includes accessing said first secure con- 
tainer rule from said second secure container. 

63. A method as in claim 58, further including: 

using information contained in or addressed by said 3Q 
descriptive data structure to at least in part identify or 
generate at least one rule to govern at least one aspect 
of access to or use of said first secure container content. 

64. A method as in claim 58, in which: 

said creation of said first secure container occurs at a first 35 
data processing arrangement located at a first site; 
said first data processing arrangement including a com- 
munications port; and 
said method further includes: 

prior to said step of accessing said descriptive data 40 
structure, said first data processing arrangement 
receiving said descriptive data structure from a sec- 
ond data processing arrangement located at a second 
site, 

said receipt occurring through said first data process- 45 
ing arrangement communications port. 

65. A method as in claim 64, in which: 

said descriptive data structure is received at said first data 
processing arrangement in a second secure container, 
said second secure container being governed by at least 50 
one rule controlling at least in part one aspect of 
access to or use of at least a portion of said descrip- 
tive data structure; and 
said step of accessing includes complying with said 
second secure container rule in order to obtain such 55 
access. 

66. A method as in claim 65, further including: 
including a copy of said descriptive data structure in said 

first secure container. 6Q 

67. A method as in claim 64, further comprising: 

at said first processing site, receiving said metadata 
through said communications port. 

68. A method as in claim 67, in which, 

said metadata is received separately from said descriptive 65 
data structure. 

69. A method as in claim 68, in which: 
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said descriptive data structure includes a reference to said 
metadata, 

a process running at said first data processing arrangement 
accesses said reference, and 
said process requests delivery of said metadata; 
said metadata being received through said first data pro- 
cessing arrangement communications port following 
said request. 

70. A method as in claim 69, in which: 

said metadata is received at said first data processing 
arrangement in a third secure container, said third 
secure container associated with at least one rule gov- 
erning at least in part at least one aspect of access to or 
use of said third secure container; and 

said use of said metadata in the process of creation of said 
first secure container occurs after a process running on 
said first data processing arrangement has complied 
with at least one requirement imposed by said third 
secure container rule. 

71. A method as in claim 58, in which: 

said specific information required to be included includes 
information at least in part identifying at least one 
owner or creator of at least a portion of said first secure 
container contents. 

72. A method as in claim 58, in which: 

said specific information required to be included includes 
a copyright notice. 

73. A method as in claim 58, in which: 

said descriptive data structure organization information 
includes information specifying that said first secure 
container contents will include at least a title and a text 
section referred to by said title. 

74. A method as in claim 73, in which: 

said descriptive data structure organization information 
includes information specifying that said first secure 
container contents will include at least one advertise- 
ment. 

75. A method as in claim 74, in which: 

said descriptive data structure further includes informa- 
tion relating to the location at which said title, said text 
section and said advertisement should be stored in said 
first secure container. 

76. A method as in claim 58, in which: 

at least a portion of said descriptive data structure orga- 
nization information includes information specifying 
fields relating to at least one atomic transaction. 

77. A method as in claim 76, in which: 

said atomic transaction information fields include fields 
for offer and acceptance information. 

78. A method as in claim 60, in which: 

said communicated information at least in part relates to 
a payment required for use of said descriptive data 
structure. 

79. A method as in claim 58, in which: 

said at least one rule at least in part controls at least one 
aspect of an auditing process. 

80. A method as in claim 58, in which: 

said at least one rule at least in part controls at least one 
aspect of a budgeting process. 

81. A method as in claim 58, in which said method is 
carried out at least in part on a secure electronic appliance. 

82. A method of using a descriptive data structure includ- 
ing: 

at a first data processing arrangement of a value chain 
participant, receiving a descriptive data structure, 
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said descriptive data structure including 

a template for the organization of content in a secure 
container; 

at said first data processing arrangement, creating a first 
secure container, said first secure container including: 5 
content organized at least in part in accordance with 

said template; and 
at least one rule designed to at least in part govern at 

least one access to or use of at least a portion of said 

content; 30 
communicating said first secure container to a second 

data processing arrangement located at or associated 

with a downstream value chain participant; and 
said downstream value chain participant opening said 

first secure container to retrieve at least a portion of 3S 

said contents, 

said opening step including complying with at least 
one requirement imposed by a first of said first 
container rule(s). 

83. A method as in claim 82, in which: 20 
said descriptive data structure is received at said first data 

processing arrangement in a second secure container; 

said second secure container being associated with at 
least one rule governing at least in part at least one 
aspect of access to or use of at least a portion of said 25 
descriptive data structure; and 

prior to said step of creating said first secure container, 
at least a portion of said descriptive data structure is 
accessed from said second secure container, 
said access including complying with at least one 30 
requirement imposed by said second secure con- 
tainer rule. 

84. A method as in claim 83, in which: 

said first secure container further includes at least a 
portion of said descriptive data structure. 35 

85. A method as in claim 83, in which: 

said first secure container rule is at least in part specified 
by information in said descriptive data structure. 

86. A method as in claim 85, in which: 

40 

said first secure container rule requires that at least one 
use of at least a portion of said first secure container 
content be directly or indirectly reported to a clearing- 
house. 

87. A method as in claim 86, in which: 

45 

said reporting includes a payment. 

88. A method as in claim 87, further including: 

prior to said step of receiving said descriptive data struc- 
ture at said first data processing arrangement, commu- 
nicating said descriptive data structure from a third data 50 
processing arrangement to said first data processing 
arrangement, 

said third data processing arrangement being associated 
with at least one clearinghouse. 

89. A method as in claim 88, further including: 55 
prior to said step of communicating said descriptive data 

structure from said third data processing arrangement 
to said first data processing arrangement, said third data 
processing arrangement receiving said descriptive data 
structure from a fourth data processing arrangement; 60 
said descriptive data structure being communicated from 
said fourth data processing arrangement to said third 
data processing arrangement in a third secure container, 
said third secure container including said descriptive 

data structure, 65 
said third secure container being associated with at 

least one rule governing at least one aspect of access 
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to or use of said descriptive data structure contained 

in said third secure container; and 
prior to communication of said descriptive data structure 
from said third data processing arrangement to said first 
data processing arrangement, at least one process at 
said third data processing arrangement complying with 
at least one requirement imposed by said third secure 
container rule. 

90. A method as in claim 89, in which: 

said step of said third data processing arrangement com- 
plying with said at least one requirement includes said 
third data processing arrangement packaging said 
descriptive data structure into said second secure 
container, said packaging being at least in part gov- 
erned by said third secure container rule. 

91. A method as in claim 90, in which: 

said step of said third data processing arrangement com- 
plying with said at least one requirement includes said 
third data processing arrangement associating at least 
one rule with said second secure container. 

92. A method as in claim 91, in which: 

said descriptive data structure includes information relat- 
ing to organization of data relating to a transaction, 
said information including information regarding price. 

93. A method as in claim 82, in which: 

a second of said first container rules at least in part 
controls at least one aspect of an auditing process. 

94. A method as in claim 82, in which: 

a second of said first container rules at least in part 
controls at least one aspect of a budgeting process. 

95. A method as in claim 82, in which said second data 
processing arrangement includes a secure electronic appli- 
ance. 

96. A data processing system including: 

a first data processing arrangement including: 

means for creating a first descriptive data structure, said 
first descriptive data structure including: 
information relating to the organization of data in a 

first secure container; and 
information relating to at least one attribute of said 
first data processing arrangement; 
said information including information relating to 
the level of security present at said first data 
processing arrangement; 
means for communicating said first descriptive data 
structure to a second data processing arrangement; 
a second data processing arrangement including: 

means for receiving said first descriptive data structure 

from said first data processing arrangement; 
means for receiving said first secure container; 
means for accessing at least a portion of said descrip- 
tive data structure; and 
means for using said first data processing arrangement 
attribute information in determining at least one use 
to be made of at least a portion of said first secure 
container. 

97. A system as in claim 96, in which: 

said second data processing arrangement means for using 
said first data processing arrangement attribute infor- 
mation includes 

means for identifying at least one attribute of the 
security present at said first data processing arrange- 
ment; and 

means for using said security information at least in 
part to specify at least one operation involving said 
first secure container. 
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98. A system as in claim 97, in which: 
said first descriptive data structure includes a first target 

data block, 

said first target data block containing information 
designed for a first target environment; and 
said second data processing arrangement includes means 
for identifying and using said first target data block. 

99. A system as in claim 98, in which: 
said first descriptive data structure includes a second 

target data block; 

said second target data block containing information 
designed for a second target environment which 
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differs in at least one respect from said first target 
environment; and 
said second data processing arrangement includes said 
first target environment but not said second target 
environment. 

100. A system as in claim 99, in which: 

said first target environment and said second target envi- 
ronment are incompatible in at least one respect. 

101. A system as in claim 96, in which said first data 
processing arrangement includes a secure electronic appli- 
ance. 

***** 



11/15/2003, EAST version: 1.4.1 



